Small ping on this one - WiFi builds for Heltec v2 and LilyGo T-Lora V2.1_1.6 are still failing on current dev.

I don't think the is the correct way to fix this issue. The Heltec V2 works perfectly well with Queue Size 256. The way to fix it is to reduce MAX_CONTACTS. At the moment MAX_CONTACTS is currently set to 160 in platformio.ini ... this is way too many. If you reduce MAX_CONTACTS to 100 then you can keep QueueSize as 256.

I think so — I introduced this issue in #1334. 🫣

Originally, the queue size was set to 16. I increased it to 256 (like the other companions), which has caused this issue.

The question is: what should have higher priority — storing more messages offline or supporting more contacts?

350 contacts is the standard for other companions, so 160 contacts is already relatively low. (My own contact list is already full with 350 rotating companions.)

I've been using Heltec V2 for over a year - ever since the first release of MC ... queue size has always been 256 in every version I've used. I've noticed that the builds failed recently - but that's because someone increased MAX_CONTACTS to 160. Reducing MAX_CONTACTS back down to a sensible value fixes the problem.

In reality, people shouldn't need 100s of contacts in their Companion... people disable AutoAdd and use the Discover List to decide which Contacts to add to the Companion's Contact list. AndyK posted a video a while back suggesting this is a better way to manage Contacts - use the Discovered List (which is stored in the App, not the Companion) and only add Contacts to the Companion that you actually interact with on a daily basis.

Companion WiFi uses more SRAM as it stores the WiFi credentials - but again - dropping the MAX_CONTACTS back down to a sensible value fixes the issue.

I would much rather have a larger offline message queue, than wasting storage space for contacts that aren't needed.

ever since the first release of MC ... queue size has always been 256 in every version I've used.

For the WiFi build, this was definitely not the case. Liam also mentioned that the WiFi companions were missed when the queue size was increased (see comment in #1331).

If you look at my changes in #1334, you’ll see that I just added OFFLINE_QUEUE_SIZE=256 to the WiFi companion section. Immediately after that change, the WiFi build started to fail.
I don’t own a v2 myself, but since I maintain the WiFi builds for the patcher, I noticed right away that this introduced a build issue.

I don’t have a strong preference for a specific solution, but it would be good to get this resolved at some point. For now, I’m applying this PR manually each time I build a new batch of firmware files.

You are correct re WiFi build - that was added fairly recently - but the OFFLINE_QUEUE_SIZE for Companion BLE has always been 256. As I say - the problem is we've always been sailing pretty close to the wind with memory size in the V2, and MAX_CONTACTS has always been set lower than other variants precisely for this reason - there simply isn't enough memory available in the V2 for the same number of Contacts as some of the other variants.

I noticed that the WiFi build failed for the V2 and suggested in Discord to Scott & Recof that we should reduce the MAX_CONTACTS for the WiFi variant to allow for the extra space required for the WiFi credentials.

I will always take offline message storage over Contacts any day of the week - especially when Contacts can be more effectively managed using the Discovered List.

Reducing offline queue size to 64 is a bad idea i.m.h.o @recrof @ripplebiz

especially when Contacts can be more effectively managed using the Discovered List.

I agree - we could probably even omit repeaters from the contact list entirely if the tools (especially path and trace) also considered repeaters from the discovery list. But that’s a separate topic.

FYI I'm using a Heltec V2 WiFi Companion with offline queue size 256 and max contacts 100 - this combo fits in the available space.

Also using Heltec V2 Companion BLE with offline queue size 256 and max contacts 140. So there's definitely no need to reduce the offline queue size as this can be managed through setting the MAX_CONTACTS correctly for the different flavours.

@MikesAllotment @olanwe I would love to see if you can flash this PR #1601 and see how much it cleans up your storage.

You can build it here: https://mcimages.weebl.me/?commitId=fix/onetime-blob-cleanup